
%% bare_jrnl.tex
%% V1.4
%% 2012/12/27
%% by Michael Shell
%% see http://www.michaelshell.org/
%% for current contact information.
%%
%% This is a skeleton file demonstrating the use of IEEEtran.cls
%% (requires IEEEtran.cls version 1.8 or later) with an IEEE journal paper.
%%
%% Support sites:
%% http://www.michaelshell.org/tex/ieeetran/
%% http://www.ctan.org/tex-archive/macros/latex/contrib/IEEEtran/
%% and
%% http://www.ieee.org/



% *** Authors should verify (and, if needed, correct) their LaTeX system  ***
% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
% *** with production work. IEEE's font choices can trigger bugs that do  ***
% *** not appear when using other class files.                            ***
% The testflow support page is at:
% http://www.michaelshell.org/tex/testflow/


%%*************************************************************************
%% Legal Notice:
%% This code is offered as-is without any warranty either expressed or
%% implied; without even the implied warranty of MERCHANTABILITY or
%% FITNESS FOR A PARTICULAR PURPOSE! 
%% User assumes all risk.
%% In no event shall IEEE or any contributor to this code be liable for
%% any damages or losses, including, but not limited to, incidental,
%% consequential, or any other damages, resulting from the use or misuse
%% of any information contained here.
%%
%% All comments are the opinions of their respective authors and are not
%% necessarily endorsed by the IEEE.
%%
%% This work is distributed under the LaTeX Project Public License (LPPL)
%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
%% distributed and modified. A copy of the LPPL, version 1.3, is included
%% in the base LaTeX documentation of all distributions of LaTeX released
%% 2003/12/01 or later.
%% Retain all contribution notices and credits.
%% ** Modified files should be clearly indicated as such, including  **
%% ** renaming them and changing author support contact information. **
%%
%% File list of work: IEEEtran.cls, IEEEtran_HOWTO.pdf, bare_adv.tex,
%%                    bare_conf.tex, bare_jrnl.tex, bare_jrnl_compsoc.tex,
%%                    bare_jrnl_transmag.tex
%%*************************************************************************

% Note that the a4paper option is mainly intended so that authors in
% countries using A4 can easily print to A4 and see how their papers will
% look in print - the typesetting of the document will not typically be
% affected with changes in paper size (but the bottom and side margins will).
% Use the testflow package mentioned above to verify correct handling of
% both paper sizes by the user's LaTeX system.
%
% Also note that the "draftcls" or "draftclsnofoot", not "draft", option
% should be used if it is desired that the figures are to be displayed in
% draft mode.
%
\documentclass[journal]{IEEEtran}
%
% If IEEEtran.cls has not been installed into the LaTeX system files,
% manually specify the path to it like:
% \documentclass[journal]{../sty/IEEEtran}





% Some very useful LaTeX packages include:
% (uncomment the ones you want to load)


% *** MISC UTILITY PACKAGES ***
%
%\usepackage{ifpdf}
% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
% compilation based on whether the output is pdf or dvi.
% usage:
% \ifpdf
%   % pdf code
% \else
%   % dvi code
% \fi
% The latest version of ifpdf.sty can be obtained from:
% http://www.ctan.org/tex-archive/macros/latex/contrib/oberdiek/
% Also, note that IEEEtran.cls V1.7 and later provides a builtin
% \ifCLASSINFOpdf conditional that works the same way.
% When switching from latex to pdflatex and vice-versa, the compiler may
% have to be run twice to clear warning/error messages.






% *** CITATION PACKAGES ***
%
\usepackage{cite}
% cite.sty was written by Donald Arseneau
% V1.6 and later of IEEEtran pre-defines the format of the cite.sty package
% \cite{} output to follow that of IEEE. Loading the cite package will
% result in citation numbers being automatically sorted and properly
% "compressed/ranged". e.g., [1], [9], [2], [7], [5], [6] without using
% cite.sty will become [1], [2], [5]--[7], [9] using cite.sty. cite.sty's
% \cite will automatically add leading space, if needed. Use cite.sty's
% noadjust option (cite.sty V3.8 and later) if you want to turn this off
% such as if a citation ever needs to be enclosed in parenthesis.
% cite.sty is already installed on most LaTeX systems. Be sure and use
% version 4.0 (2003-05-27) and later if using hyperref.sty. cite.sty does
% not currently provide for hyperlinked citations.
% The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/cite/
% The documentation is contained in the cite.sty file itself.






% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
  \usepackage[pdftex]{graphicx}
  \usepackage{wrapfig}
  \usepackage{subfig}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../pdf/}{../jpeg/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
  % will default to the driver specified in the system graphics.cfg if no
  % driver is specified.
  % \usepackage[dvips]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../eps/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.eps}
\fi
% graphicx was written by David Carlisle and Sebastian Rahtz. It is
% required if you want graphics, photos, etc. graphicx.sty is already
% installed on most LaTeX systems. The latest version and documentation
% can be obtained at: 
% http://www.ctan.org/tex-archive/macros/latex/required/graphics/
% Another good source of documentation is "Using Imported Graphics in
% LaTeX2e" by Keith Reckdahl which can be found at:
% http://www.ctan.org/tex-archive/info/epslatex/
%
% latex, and pdflatex in dvi mode, support graphics in encapsulated
% postscript (.eps) format. pdflatex in pdf mode supports graphics
% in .pdf, .jpeg, .png and .mps (metapost) formats. Users should ensure
% that all non-photo figures use a vector format (.eps, .pdf, .mps) and
% not a bitmapped formats (.jpeg, .png). IEEE frowns on bitmapped formats
% which can result in "jaggedy"/blurry rendering of lines and letters as
% well as large increases in file sizes.
%
% You can find documentation about the pdfTeX application at:
% http://www.tug.org/applications/pdftex





% *** MATH PACKAGES ***
%
%\usepackage[cmex10]{amsmath}
% A popular package from the American Mathematical Society that provides
% many useful and powerful commands for dealing with mathematics. If using
% it, be sure to load this package with the cmex10 option to ensure that
% only type 1 fonts will utilized at all point sizes. Without this option,
% it is possible that some math symbols, particularly those within
% footnotes, will be rendered in bitmap form which will result in a
% document that can not be IEEE Xplore compliant!
%
% Also, note that the amsmath package sets \interdisplaylinepenalty to 10000
% thus preventing page breaks from occurring within multiline equations. Use:
%\interdisplaylinepenalty=2500
% after loading amsmath to restore such page breaks as IEEEtran.cls normally
% does. amsmath.sty is already installed on most LaTeX systems. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/amslatex/math/





% *** SPECIALIZED LIST PACKAGES ***
%
\usepackage{algorithm}
\usepackage{algorithmic}
% algorithmic.sty was written by Peter Williams and Rogerio Brito.
% This package provides an algorithmic environment fo describing algorithms.
% You can use the algorithmic environment in-text or within a figure
% environment to provide for a floating algorithm. Do NOT use the algorithm
% floating environment provided by algorithm.sty (by the same authors) or
% algorithm2e.sty (by Christophe Fiorio) as IEEE does not use dedicated
% algorithm float types and packages that provide these will not provide
% correct IEEE style captions. The latest version and documentation of
% algorithmic.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithms/
% There is also a support site at:
% http://algorithms.berlios.de/index.html
% Also of interest may be the (relatively newer and more customizable)
% algorithmicx.sty package by Szasz Janos:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithmicx/




% *** ALIGNMENT PACKAGES ***
%
%\usepackage{array}
% Frank Mittelbach's and David Carlisle's array.sty patches and improves
% the standard LaTeX2e array and tabular environments to provide better
% appearance and additional user controls. As the default LaTeX2e table
% generation code is lacking to the point of almost being broken with
% respect to the quality of the end results, all users are strongly
% advised to use an enhanced (at the very least that provided by array.sty)
% set of table tools. array.sty is already installed on most systems. The
% latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/tools/


% IEEEtran contains the IEEEeqnarray family of commands that can be used to
% generate multiline equations as well as matrices, tables, etc., of high
% quality.




% *** SUBFIGURE PACKAGES ***
%\ifCLASSOPTIONcompsoc
%  \usepackage[caption=false,font=normalsize,labelfont=sf,textfont=sf]{subfig}
%\else
%  \usepackage[caption=false,font=footnotesize]{subfig}
%\fi
% subfig.sty, written by Steven Douglas Cochran, is the modern replacement
% for subfigure.sty, the latter of which is no longer maintained and is
% incompatible with some LaTeX packages including fixltx2e. However,
% subfig.sty requires and automatically loads Axel Sommerfeldt's caption.sty
% which will override IEEEtran.cls' handling of captions and this will result
% in non-IEEE style figure/table captions. To prevent this problem, be sure
% and invoke subfig.sty's "caption=false" package option (available since
% subfig.sty version 1.3, 2005/06/28) as this is will preserve IEEEtran.cls
% handling of captions.
% Note that the Computer Society format requires a larger sans serif font
% than the serif footnote size font used in traditional IEEE formatting
% and thus the need to invoke different subfig.sty package options depending
% on whether compsoc mode has been enabled.
%
% The latest version and documentation of subfig.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/subfig/




% *** FLOAT PACKAGES ***
%
%\usepackage{fixltx2e}
% fixltx2e, the successor to the earlier fix2col.sty, was written by
% Frank Mittelbach and David Carlisle. This package corrects a few problems
% in the LaTeX2e kernel, the most notable of which is that in current
% LaTeX2e releases, the ordering of single and double column floats is not
% guaranteed to be preserved. Thus, an unpatched LaTeX2e can allow a
% single column figure to be placed prior to an earlier double column
% figure. The latest version and documentation can be found at:
% http://www.ctan.org/tex-archive/macros/latex/base/


%\usepackage{stfloats}
% stfloats.sty was written by Sigitas Tolusis. This package gives LaTeX2e
% the ability to do double column floats at the bottom of the page as well
% as the top. (e.g., "\begin{figure*}[!b]" is not normally possible in
% LaTeX2e). It also provides a command:
%\fnbelowfloat
% to enable the placement of footnotes below bottom floats (the standard
% LaTeX2e kernel puts them above bottom floats). This is an invasive package
% which rewrites many portions of the LaTeX2e float routines. It may not work
% with other packages that modify the LaTeX2e float routines. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/sttools/
% Do not use the stfloats baselinefloat ability as IEEE does not allow
% \baselineskip to stretch. Authors submitting work to the IEEE should note
% that IEEE rarely uses double column equations and that authors should try
% to avoid such use. Do not be tempted to use the cuted.sty or midfloat.sty
% packages (also by Sigitas Tolusis) as IEEE does not format its papers in
% such ways.
% Do not attempt to use stfloats with fixltx2e as they are incompatible.
% Instead, use Morten Hogholm'a dblfloatfix which combines the features
% of both fixltx2e and stfloats:
%
% \usepackage{dblfloatfix}
% The latest version can be found at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/dblfloatfix/




%\ifCLASSOPTIONcaptionsoff
%  \usepackage[nomarkers]{endfloat}
% \let\MYoriglatexcaption\caption
% \renewcommand{\caption}[2][\relax]{\MYoriglatexcaption[#2]{#2}}
%\fi
% endfloat.sty was written by James Darrell McCauley, Jeff Goldberg and 
% Axel Sommerfeldt. This package may be useful when used in conjunction with 
% IEEEtran.cls'  captionsoff option. Some IEEE journals/societies require that
% submissions have lists of figures/tables at the end of the paper and that
% figures/tables without any captions are placed on a page by themselves at
% the end of the document. If needed, the draftcls IEEEtran class option or
% \CLASSINPUTbaselinestretch interface can be used to increase the line
% spacing as well. Be sure and use the nomarkers option of endfloat to
% prevent endfloat from "marking" where the figures would have been placed
% in the text. The two hack lines of code above are a slight modification of
% that suggested by in the endfloat docs (section 8.4.1) to ensure that
% the full captions always appear in the list of figures/tables - even if
% the user used the short optional argument of \caption[]{}.
% IEEE papers do not typically make use of \caption[]'s optional argument,
% so this should not be an issue. A similar trick can be used to disable
% captions of packages such as subfig.sty that lack options to turn off
% the subcaptions:
% For subfig.sty:
% \let\MYorigsubfloat\subfloat
% \renewcommand{\subfloat}[2][\relax]{\MYorigsubfloat[]{#2}}
% However, the above trick will not work if both optional arguments of
% the \subfloat command are used. Furthermore, there needs to be a
% description of each subfigure *somewhere* and endfloat does not add
% subfigure captions to its list of figures. Thus, the best approach is to
% avoid the use of subfigure captions (many IEEE journals avoid them anyway)
% and instead reference/explain all the subfigures within the main caption.
% The latest version of endfloat.sty and its documentation can obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/endfloat/
%
% The IEEEtran \ifCLASSOPTIONcaptionsoff conditional can also be used
% later in the document, say, to conditionally put the References on a 
% page by themselves.




% *** PDF, URL AND HYPERLINK PACKAGES ***
%
%\usepackage{url}
% url.sty was written by Donald Arseneau. It provides better support for
% handling and breaking URLs. url.sty is already installed on most LaTeX
% systems. The latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/url/
% Basically, \url{my_url_here}.




% *** Do not adjust lengths that control margins, column widths, etc. ***
% *** Do not use packages that alter fonts (such as pslatex).         ***
% There should be no need to do such things with IEEEtran.cls V1.6 and later.
% (Unless specifically asked to do so by the journal or conference you plan
% to submit to, of course. )


% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor}

\begin{document}
%
% paper title
% can use linebreaks \\ within to get better formatting as desired
% Do not put math or special symbols in the title.
\title{Vegas over Access Point: Making Room for 
Thin Client Game Systems in a Wireless Home}
%
%
% author names and IEEE memberships
% note positions of commas and nonbreaking spaces ( ~ ) LaTeX will not break
% a structure at a ~ so this keeps an author's name from being broken across
% two lines.
% use \thanks{} to gain access to the first footnote area
% a separate \thanks must be used for each paragraph as LaTeX2e's \thanks
% was not built to handle multiple paragraphs
%

\author{\IEEEauthorblockN{
 Armir~Bujari, %
 Michele~Massaro and %
 Claudio~E.~Palazzi~\IEEEmembership{Member,~IEEE}}%
 \thanks{Manuscript received October 14, 2014; revised October 12, 2014. Corresponding author: C. E. Palazzi.}
 \thanks{A. Bujari, M. Massaro, and C. E. Palazzi are with the Department of Mathematics, University of Padua, Padua, Italy (e-mail: \{abujari,cpalazzi\}@math.unipd.it; mmassaro@studenti.unipd.it)}}%


% note the % following the last \IEEEmembership and also \thanks - 
% these prevent an unwanted space from occurring between the last author name
% and the end of the author line. i.e., if you had this:
% 
% \author{....lastname \thanks{...} \thanks{...} }
%                     ^------------^------------^----Do not want these spaces!
%
% a space would be appended to the last name and could cause every name on that
% line to be shifted left slightly. This is one of those "LaTeX things". For
% instance, "\textbf{A} \textbf{B}" will typeset as "A B" not "AB". To get
% "AB" then you have to do: "\textbf{A}\textbf{B}"
% \thanks is no different in this regard, so shield the last } of each \thanks
% that ends a line with a % and do not let a space in before the next \thanks.
% Spaces after \IEEEmembership other than the last one are OK (and needed) as
% you are supposed to have spaces between the names. For what it is worth,
% this is a minor point as most people would not even notice if the said evil
% space somehow managed to creep in.



% The paper headers
\markboth{Journal of \LaTeX\ Class Files,~Vol.~11, No.~4, December~2012}%
{Shell \MakeLowercase{\textit{et al.}}: Bare Demo of IEEEtran.cls for Journals}
% The only time the second header will appear is for the odd numbered pages
% after the title page when using the twoside option.
% 
% *** Note that you probably will NOT want to include the author's ***
% *** name in the headers of peer review papers.                   ***
% You can use \ifCLASSOPTIONpeerreview for conditional compilation here if
% you desire.




% If you want to put a publisher's ID mark on the page you can do it like
% this:
%\IEEEpubid{0000--0000/00\$00.00~\copyright~2012 IEEE}
% Remember, if you use this you must call \IEEEpubidadjcol in the second
% column for its text to clear the IEEEpubid mark.



% use for special paper notices
%\IEEEspecialpapernotice{(Invited Paper)}




% make the title area
\maketitle

% As a general rule, do not put math, special symbols or citations
% in the abstract or keywords.
\begin{abstract}
Cloud-based entertainment is gaining momentum. With the cost of commodity hardware lowering by the day and the consumer market penetration of in-house digital entertainment systems, a new generation of interactive services has come into being. This new technological wave has launched new content producers and providers which are rapidly adapting to match the consumer demand. In this context, thin client or cloud based gaming is attracting much attention, shifting the computational burden to the cloud while the consumer enjoys a fat video feed accessed through its thin client via the shared wireless gateway. However, this interaction model poses a new challenge demanding for specific networking solutions aimed at addressing the heterogeneous flow coexistence problem at the home wireless gateway.
In this article we propose a solution to the problem by devising a TCP Vegas-like congestion control algorithm deployed on top of the home gateway. From here the name Vegas over Access Point (VoAP).
Our solution requires no modifications at regular protocols, servers, routers and client, hence guaranteeing its factual deployment. Experimental assessment with real traffic traces shows that our solution effectively and fully addresses the problem.
\end{abstract}

% Note that keywords are not normally used for peerreview papers.
\begin{IEEEkeywords}
Cloud gaming, interactivity, TCP Vegas, thin client game, wireless.
\end{IEEEkeywords}






% For peer review papers, you can put extra information on the cover
% page as needed:
% \ifCLASSOPTIONpeerreview
% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
% \fi
%
% For peerreview papers, this IEEEtran command inserts a page break and
% creates the second title. It will be ignored for other modes.
\IEEEpeerreviewmaketitle



\section{Introduction}
% The very first letter is a 2 line initial drop letter followed
% by the rest of the first word in caps.
% 
% form to use if the first word consists of a single letter:
% \IEEEPARstart{A}{demo} file is ....
% 
% form to use if you need the single drop letter followed by
% normal text (unknown if ever used by IEEE):
% \IEEEPARstart{A}{}demo file is ....
% 
% Some journals put the first two words in caps:
% \IEEEPARstart{T}{his demo} file is ....
% 
% Here we have the typical use of a "T" for an initial drop letter
% and "HIS" in caps to complete the first word.
\IEEEPARstart{U}{ntil} recently, home entertainment was confined to either a cable box, an optical disc or to an Internet server download. Today, with better access to broadband, the advent of digital home entertainment systems and online computing services, many of us get the bulk of their content streamed directly to our devices from the cloud. This has given spur to a two-way interaction model and personalized content, enabling new intelligent consumer services. The emergent cloud gaming paradigm, also referred to as thin client gaming, is one representative example in which the game engine resides in the provider's cloud and the outcome is streamed directly as video content to the consumer devices to be accessed through a thin client (e.g., OnLive~\cite{OnLive}). This allows consumers to access the game without a console, rendering the end-device unimportant as the computing burden is shifted to the cloud~\cite{Claypool2012}.

%In this context, home entertainment has become an elegant reality and an integral part of our everyday life.
In this context, a key enabler component is embodied by the wireless gateway providing shared access to the cloud, bringing the fun at our preferred location at home, while the transport protocols remain those that have been in use for the last 30 years: the Transmission Control Protocol (TCP) for elastic (e.g., downloading) applications and the User Datagram Protocol (UDP) for real-time ones (e.g., video/music streaming, online gaming).

Unfortunately, despite this colorful picture a new problem emerges, requiring the employment of a specific solution. This problem resides in the contrasting \emph{modus operandi} of the underlying 
transport protocols being employed from the applications sharing the same wireless bottleneck. Indeed, applications with real-time requirements such as cloud gaming require fast delivery 
of gaming events and updates, whereas high data rates are desirable for elastic, download sessions. In contrast to classic gaming systems, cloud based games pose additional bandwidth requirements 
on the shared wireless downlink, with fat video chunks being streamed down to the device from the cloud~\cite{Claypool2012,BoussettaMaggiorini}. This further exacerbates the TCP vs UDP quarrel and, in particular, it jeopardizes 
the interactivity and responsiveness of gaming sessions, with TCPs aggressive behavior being the main cause~\cite{refPerPacketLatency}.

Technical motivations and the conflicts that arise are explained in detail in Section II; yet, in synthesis, the fact is that elastic traffic is still considered to be the main traffic type run by consumers on the wireless channel. In this context, providing reliable delivery and high throughput to this kind of applications: i) TCP and its congestion control functionality are employed at the transport layer, and ii) buffers and local retransmissions are extensively used at the MAC layer. However, these mechanisms in conjunction, have been demonstrated to harm real-time applications by increasing the per-packet delivery latency.
%The reverse problem also stands, where UDP-based flows lacking a control mechanism exhibit aggressive behavior toward TCP-based ones ~\cite{KuroseRoss}.

Tackling this issue, delay-based TCP congestion protocols have been proposed, employing packet Round Trip Time (RTT) rather than losses to prevent congestion. In this realm, TCP Vegas is the main candidate~\cite{vegas1}. However, its adoption is hindered by the widespread deployment and use of loss-based protocols.
The only way to employ TCP Vegas in practice would be to completely dismiss all loss-based TCP versions and, needless to say, this is not a feasible option.

In this article, we show how to practically exploit the benefits of delay-based protocols, intervening only at the wireless gateway, hence guaranteeing a factual deploy of the solution. In essence, the gateway is enhanced with an algorithm that automatically limits TCP flows through their advertised window when the channel is near to the saturation, thus avoiding long queues (and queuing delay) as well as packet loss, while keeping the TCP-based flows at a data rate level which corresponds to a full utilization of the available bandwidth. This approach is similar in spirit to TCP Vegas, hence the name Vegas over Access Point (VoAP).
As a result of our proposal, elastic applications achieve high data throughput, while real-time applications maintain a low latency.

The rest of the paper is organized as follows. Section~II discusses the technical background and issues at the basis of this work, while Section~III overviews related work in scientific literature. VoAP's idea, properties and algorithmic details are presented in Section~IV. The experimental testbed is described in Section~V and obtained results are analysed in Section~VI. Finally, Section~VII concludes this paper.

\section{Technical Background and Problem Statement}

In this section we follow up on the heterogeneous flow interference problem in the home gateway scenario, providing further technical insights on the symptom and why it emerges.
First of all, it is important to remind that measurements on a real OC48 link show that the available capacity in the Internet core is generally larger than the aggregate utilized by transiting flows~\cite{OC48}. We can hence assume that the bottleneck is located at the edge of the path connecting a sender and a receiver: i.e., the DSL link connecting the house to the Internet or the domestic Wi-FI. Therefore, the edge of the connection is where we have to act if we want to address congestion related problems.

Applications can be grouped into two main classes depending on which protocol they use at the transport layer: TCP or UDP. TCP is a protocol with embedded mechanisms aimed at guaranteeing reliable and in-order delivery of data packets. These are desirable features which are exploited by elastic applications, those involving content download/transmission. Through the rest of the article, with the term TCP we refer to the legacy TCP version, i.e., TCP New Reno.

A very important feature of TCP is represented by its congestion control functionality. Through it, every TCP flow probes the link with higher and higher data rates eventually filling up the channel. At this point, packets will be queued at the buffer associated with the bottleneck link until it overflows, causing packet losses. TCP retransmits the lost packets, and halves its sending rate to diminish the congestion level. Finally, the regular increase of the sending rate is reestablished and the same process is repeated.

With UDP, packets are immediately sent toward the receiver with a data rate determined by the sender. UDP does not guarantee reliable and ordered delivery of packets but, at the same time, its small overhead and lack of retransmissions make it generally less prone to generate delays. For this reason, UDP is usually employed by applications characterized by stringent real-time constraints that can tolerate sporadic packet losses (i.e., audio/video streaming, online games). The lack of congestion control functionalities of UDP had lead the scientific community to consider UDP as unfair toward TCP. Indeed, citing from~\cite{KuroseRoss}: \emph{``Although commonly done today, running multimedia applications over UDP is controversial to say the least. The lack of congestion control in UDP can result in high loss rates between a UDP sender and receiver, and the crowding out of TCP sessions - a potentially serious problem.''}

Even if this could have been true several years ago, when the available bandwidth was very scarce, the broadband connectivity offered today tends to overturn this situation. Indeed, nowadays, larger and larger bandwidth is available at the network edges and the traffic generated by UDP-based applications (e.g., VoIP and classic online games) can generally be accommodated.
Even when considering bandwidth demanding UDP-based applications (e.g., real-time video streaming and thin client games) some flow control is operated at the application layer, decreasing
the content quality and required bandwidth for transmitting the media~\cite{Maggiorini2004,Claypool2012,dash}.
Yet, a problem emerges when downloading applications (TCP-based) coexist with real-time ones (UDP-based), the former forcing the latter to experience a scattered flow progression~\cite{sap1,WCMC2013}.
The main cause for this problem can be found in the TCP's congestion control functionality. In particular, TCP continuously probes for higher transfer rates, also queuing packets on the buffer
associated with the bottleneck of the connection. If one considers that the same connection might be shared by several devices and applications thus increasing the congestion level and queue
lengths, it is even more evident how packets can be delayed in queue, jeopardizing the interactivity requirements of real-time applications.

This negative situation is further worsened by factors linked to the wireless channel present at our home gateways. First, the wireless medium allows the transmission of only one packet at
a time and is not full-duplex as wired links. Packets have hence to wait their turn to be transmitted. Second, as interference, errors, fading, and mobility may cause packet loss, the IEEE
802.11 MAC layer reacts through local retransmissions (4 at most~\cite{80211}) which, in turn, cause subsequent packets to wait in queue until the preceding ones or their retransmissions
eventually reach the receiver. Last but not least, the back-off mechanism of the IEEE 802.11 introduces an increasing amount of time before attempting again a transmission.

Under these conditions, delay increments of online game packets can hit also tens of milliseconds, representing a huge waste of time when trying to deliver real-time information for entertainment
services. As a reference benchmark, it is common belief that transmission delays of interactive online games should be inferior to 100 ms, with a maximum endurable value of 150 ms~\cite{PantelWolf2002}.

A recent comprehensive study analysing the network traffic of the well known thin client game system (OnLive) reports downstream bitrates similar to high-definition live video with fat, 
frequent packets being streamed to the client, while on the other side, upstream traffic has lower data rates, comparable with classic online game upstream traffic. This in and out-flow characteristics if not dealt properly in the wireless AP could worsen the game interactivity rendering the session unbearable.

\section{Related Works}

Aimed at providing Quality of Service (QoS) capabilities to WLANs, the IEEE~802.11e has been proposed~\cite{80211e}. Its design allows to discriminate among various kinds of flows, assigning
priorities through specific parameter settings. In particular, flows with different priorities are enqueued into different buffers, each having a specific contention time. As a result, packets
belonging to high priority traffic have higher chances to be transmitted before low priority ones. Yet, it is not clear how the access point (AP) could classify the incoming traffic.
The sender has to mark each of its packets or flows with a priority level; unfortunately, this would imply the modification of all senders operability or applications, thus strongly affecting
the factual deployment of this protocol.

Solutions have been proposed to avoid the latency increase specifically generated by TCP New Reno's congestion control. As most of the problem resides in the protocol itself, an approach
would be to switch from the legacy protocol to a delay-based one, TCP Vegas-like. Indeed TCP Vegas is able to detect the congestion in advance using the RTT fluctuation of the packets.
Simply said, it increases the transfer speed when the delay is under an $\alpha$ threshold and decreases it when the delay is over $\beta$ ($\alpha$ \textless $\beta$). In this way, it is
not necessary to lose a packet in order to detect congestion, rather it can be detected before it happens. As a desirable side effect, this also avoids the creation of bottleneck queues and
corresponding queuing delays that would harm any interactive, real-time applications.

Unfortunately, TCP Vegas flows cannot coexist with loss-based ones, e.g., generated by TCP New Reno and other legacy real life TCP versions; loss-based flows generate congestion by their nature,
which induces delay-based ones to slow down their transfer rate. The result is that loss-based flows will capture almost all the channel~\cite{vegas1,vegas2,sap1}. This incompatibility with
legacy protocols made TCP Vegas hardly applicable.

Instead, a solution that would not require a modification of Internet protocols was proposed in~\cite{sap1,sap2} and named Smart Access Point with Low Advertised Window (SAP-LAW). Basically,
this solution leverages on the ability of the AP to monitor all traffic passing through and, by appropriate on-the-fly modifications of the advertised window, prevents TCP-based flows 
from exceeding their fair bandwidth share.

%%The algorithm detects the ongoing UDP traffic, and computes the available bandwidth, as well as the corresponding appropriate advertised window, for each flow through (1) (three flows in the example).

%%\begin{equation}\label{first}
%%\begin{split}
%%&macTCPrate_i(t)=\frac{(C-UDPtraffic(t))*RTT_i}{a_1+a_2+a_3}\\
%%&a_1=\frac{RTT_1}{avg.RTT_{min}}, a_2=\frac{RTT_2}{avg.RTT_{min}}, a_3=\frac{RTT_3}{avg.RTT_{min}} \\
%%\end{split}
%%\end{equation}

This avoids the classic TCP's congestion window fluctuations, stabilizing it to an appropriately computed value, which does not decrease the achieved throughput. Moreover, it avoids queue formation, hence alleviating delay problems for UDP packets and allowing the user to enjoy interactive, real-time services.

However, this proposal is limited as it requires an \emph{a priori} knowledge of the bottleneck capacity and the RTT of each flow; these parameters may not be always known or correctly computed or even stable enough to be used in a timely fashion.

Gateway Adaptive Pacing (GAP) proposed for multi-hop wireless networks is similar in spirit~\cite{gap1,mhop-not-gap}. GAP adds an artificial delay between any packet and its subsequently transmitted one, 
based on continuous measurements of the network. In this way the interarrival time decreases, but so does even the throughput of TCP flows, thus finding scarce applicability in our considered scenario and, in general, in the regular one-hop case.

Studies on thin client game systems so far, have been focused on traffic flow characteristics and system architecture aimed at delivering the service~\cite{Claypool2012,performanceThin}. To the best of our 
knowledge this is the first work addressing the problem of TCP/UDP flow coexistence in presence of concurrent cloud-based gaming flows.  

\section{VoAP}
\label{VoAP}

In the classic TCP protocol, the actual sending rate (i.e., the sending window) of a TCP flow is determined as the minimum between the congestion window (continuously recomputed by the sender) and the advertised window (provided by the receiver via returning ACK packets). Our idea is to dynamically modify the advertised window to limit the growth of the TCP flow's sending rate. Indeed, a good tradeoff solution between throughput and low delays could be achieved by maintaining the sending rate of the TCP flows high enough to efficiently utilize the available bandwidth and, at the same time, limited in its growth so as to not overutilize buffers. Intuitively, this way the per-packet delays are minimized by the absence of queues along the route from the sender to the receiver, while the throughput is kept elevated by the absence of packet losses that would otherwise halve the congestion window. At the same time, we exploit an existing feature of regular TCP implementations thus limiting the modifications required only to the home AP.

The advertised window is generally imposed by the receiver; however, in our case, VoAP computes its value. We decide to install VoAP on the AP as the latter represents the bottleneck of the connection and all the flows directed in the wireless home or out of it should pass through this device. In essence, VoAP monitors the ongoing traffic and the current queuing delay experienced by packets transiting through its buffer. If this queuing delay becomes too long to sustain interactive applications such as games, VoAP proceeds with appropriate on-the-fly modifications of the advertised window values in TCP ACKs so as to limit TCP flows just below the congestion level.

In the following we discuss in detail how VoAP operates in order to determine an appropriate advertised window for the TCP flows that pass through the AP.
Our algorithm addresses the aforementioned coexistence problem among heterogenous applications, while avoiding impractical assumptions that could hinder its deployment.
Below, we enumerate the desirable \textbf{Properties} that our ideal algorithm should adhere to:

\begin{enumerate}
\item it does not require any changes to current network protocols, servers, routers and clients (only the AP is modified);
\item it does not require any \textit{a priori} information about the network (e.g., the capacity of the bottleneck link or flows' RTTs);
\item UDP flows do not have to suffer from per-packet latency caused by TCP;
\item TCP flows' throughput must not be sacrificed;
\item possible congestion must be detected as soon as possible;
\item every TCP flow must be able to obtain a fair share of the available bandwidth;
\item if a TCP flow does not exploit all the bandwidth assigned by the algorithm, the leftover must be redistributed among the other flows.
\end{enumerate}

Our solution has been designed mainly for a wireless home scenario, where the bottleneck is represented by a wireless component; however, it should work even in a more  general environment (including wired connectivity). Through the rest of the section we discuss how each of the properties above is ensured by VoAP. Where applicable, we also provide a pseudocode explanation of the algorithm designed to specifically ensure a certain property or behaviour.

\textbf{\textit{1)}}
To achieve the first objective, we have taken inspiration from SAP-LAW, thus placing our solution in the AP. From this position we can monitor and act upon individual flows; at the same time, this strategy alleviates us the burden to perpetuate any client side modifications.
Using the advertised window already present in the header of a TCP ACK, it is possible to limit the amount of transiting packets and hence control the utilization of the buffers.

\textbf{\textit{2)}}
The second key ingredient of the algorithm is that it does not require any additional information from the network that would hinder its deployment in a real environment. To this end, we follow an approach similar in heart to the one used in the TCP Vegas' congestion control algorithm.

The main idea at the basis of VoAP is to monitor all TCP flows passing through the AP and measure how long packets are queued before actually being transmitted through the wireless channel.
This is the only information required and it is easily available at the AP. No modification is needed at the server, router or client side to enable VoAP. Distributing the changes as a firmware update or other means on the AP-side augments the chances of an actual deployment.

\textbf{\textit{3)}}
Algorithm 1 shows how the information about packet queueing time is exploited by VoAP in order to determine the appropriate value for the advertised window of TCP flows. In particular, we distinguish three cases. If the measured delay $IFQmaxDel$ is below the threshold $\alpha$ (line~2), the channel can be considered almost free, so the advertised window is increased, allowing the TCP to increase its transfer speed. A queuing delay between the two thresholds $\alpha$ and $\beta$ (line~12), means that the network is well utilized and not congested; for this reason the flows are left unchanged and are not acted upon. If the delay is over the $\beta$ threshold (line~20), the channel is saturated, so the TCP flows are slowed down by decrementing the advertised window value communicated though the ACKs.
In  Algorithm~1, the variable $VoAPactive$ indicates whether VoAP's capability to limit TCP flows through their advertised window is active or not; the rationale behind this feature is explained when discussing \textbf{Property~4}.

The parameters $\alpha$ and $\beta$ are expressed in milliseconds and represent the queuing delay boundaries we would like to have in our system. In particular, $\beta$ is the maximum queuing delay at the AP we tolerate. Considering that any game packet should be delivered within 150~ms at most and that this accounts for all delays (transmission, propagation, handling, queuing, etc.), we decided to set $\beta$ equal to 15~ms. Instead, the value used for $\alpha$ is set to 5~ms and the explanation is provided when discussing \textbf{Property~4}.

The queuing delays are measured during an interval of time $T$ (200~ms in our experimentation), after which Algorithm 1 is executed. Every modification of the advertised window is done on a per unit basis, so as to ensure a smooth fluctuation of the TCP flows and throughput. Moreover, these modifications are performed only after T elapses. After this, the timers are reset, and the delay sampling restarts.

Inside a timeframe T each flow is monitored it is active or not, and the bandwidth is splitted accordingly among flows in a fair way. It is therefore necessary for T to be big enough to allow for all active flows to transmit at least one packet, but also small enough not to waste the bandwidth on a non-active flow.

In Section~\ref{Resultslatency} we report the experimental results demonstrating that VoAP correctly and effectively enforces this property, maintaining a low per-packet delivery delay.

\textbf{\textit{4)}}
When a TCP flow queues packets at the bottleneck its throughput is not actually increasing: to faster transmission rates correspond longer queues at the bottleneck link with no improvement
of the receiving rate. For this reason our limitation of TCP flows through the advertised window manipulation does not lower the throughput. As anticipated, the choice of $\alpha$ and $\beta$
values imply how many packets can simultaneously reside in the bottleneck queue; this has an impact on both the per-packet latency and the throughput.
We already discussed $\beta$ value (15 ms) as the maximum delay we would like to tolerate as queuing delay. We also tested different values for $\alpha$. Parameter $\alpha$ represents
a minimum queuing delay that we would actually like to have at the AP as it ensures that the AP's buffer has a set of packets ready to be transmitted at any time and no transmitting
opportunity will be wasted.
Therefore it should be some value higher than 0 ms and lower than $\beta$. Unless choosing clearly unreasonable values, we have noticed that it had not a big impact on the performance, thus
making a possible optimization study not strictly necessary. We have hence used $\alpha$ equal to 5 ms for the experimentation presented in Section~\ref{Results} as a representative value which works well (as well as other values between 0 ms and $\beta$; we show this in Section~\ref{Resultsthroughput}.

An important portion of TCP's throughput is achieved during the slow start phase (especially, but not only, short lived ones). Therefore, VoAP should not limit the slow start phase to a linear increment as this would significantly slow down the initial growth of the sending window and throughput unless this is causing congestion. To this end, we introduce two features to our solution:
\begin{itemize}
\item VoAP's algorithm is not used if the congestion window of a TCP flow is in slow start (the value of $VoAPactive$ used in Algorithm~1 will be $false$);
\item VoAP's algorithm acts on the TCP flow only after the $\beta$ threshold is exceeded for the first time (lines 23 and 24, Algorithm~1).
\end{itemize}

In this way, the TCP flows can freely grow during the slow start phase, being limited only when they start jeopardizing the per-packet delay performance by network saturation.

In Section~\ref{Resultsthroughput} we report on experimental results that demonstrate how VoAP does not harm TCP's throughput.

\textbf{\textit{5)}} The fifth property is related to the reactivity of the algorithm; when the queue is growing it is mandatory to act quickly so as to avoid losses. To fasten the delay 
detection, the queuing delay measurements are not solely made at the end of the permanence in queue of a packet, rather also on packets that are still in queue. To achieve this, we just 
need to read the timestamp of the first packet which is always the oldest in a FIFO queue. This procedure is described in Algorithm~2.

\textbf{\textit{6)}} The sixth property ensures that a fair share of bandwidth is guaranteed to every TCP flow. To achieve this, the maximum number of outgoing packets is estimated as the 
sum of the advertised windows of every active TCP flow (variable $totalAwnd$ in Algorithm~1). Once the value is obtained, it is divided by the number of active flows, to assign a share of 
the bandwidth to each one, as can be seen in Algorithm~3.

In Section~\ref{Resultsfairness} we report the experimental results demonstrating that VoAP is fair toward concurrent TCP flows.

\textbf{\textit{7)}} This property is related to the fact that not all present flows will actually try to fully exploit their assigned bandwidth share (e.g., because of small bandwidth available
at their server). For this reason we provide a sharing function (Algorithm~4) to make the algorithm able to redistribute the bandwidth leftover.

If the congestion window of a flow is bigger than its advertised window, it means that it would be able to exploit a bigger share, so it is added to a list of candidates to receive additional bandwidth (lines~6 and 7, Algorithm~4) so as to avoid the underutilization of the channel. To ensure growing chances to those low-rate flows in case their conditions change, their limited share is oversized by 10\%.

In Section~\ref{Resultsefficient} we report the experimental results demonstrating that VoAP is efficient and redistributes unused bandwidth among TCP flows that are able to exploit it.

\begin{algorithm}
\label{Pseudocode 1}
\caption{}
\begin{algorithmic}[1]
\REQUIRE $alpha \leq beta$
\STATE $IFQmaxDel \leftarrow$ highest packet delay in the last period T
\IF{$IFQmaxDel < alpha$}
\FOR{\textbf{each} active flow \textit{i}}
\IF{$VoAPactive(i)$}
%\IF{$cwin(i) > 10$ and limitFlow[i] is true}
\STATE $awnd(i) \leftarrow awnd(i) + 1$ \COMMENT{$awnd(i)$ contains the advertised window of the flow \textit{i}}
\STATE $totalAwnd \leftarrow totalAwnd + awnd(i)$ \COMMENT{$totalAwnd$ store the sum of all the advertise windows}
\ELSE
\STATE $VoAPactive(i) \leftarrow false$
%\STATE $limitFlow[i] = false$
\ENDIF
\ENDFOR
\ENDIF

\IF{$IFQmaxDel > alpha$ and $IFQmaxDel < beta$}
\FOR{\textbf{each} active flow \textit{i}}
\IF{$VoAPactive(i)$}
%\IF{limitFlow[i] is true and $cwnd(i) < 10$}
%\STATE $awnd(i) = 10$
\STATE $awnd(i) \leftarrow cwnd(i)$
\ENDIF
\STATE $totalAwnd \leftarrow totalAwnd + awnd(i)$
\ENDFOR
\ENDIF

\IF{$IFQmaxDel > beta$}
\FOR{\textbf{each} active flow \textit{i}}
%\IF{limitFlow[i] is false}
\IF{$\neg VoAPactive(i)$}
%\STATE $limitFlow[i] \leftarrow true$
\STATE $VoAPactive \leftarrow true$
\STATE $awnd(i) \leftarrow cwnd(i)$
\ENDIF
\STATE $awnd(i) \leftarrow awnd(i) - 1$
\STATE $totalAwnd \leftarrow totalAwnd + awnd(i)$
\ENDFOR
\ENDIF
\end{algorithmic}
\end{algorithm}

\begin{algorithm}[h]
\label{Pseudocode 2}
\caption{}
\begin{algorithmic}[1]
\REQUIRE $Queue$ represent the AP's FIFO queue
\STATE $oldestInQueue \leftarrow Queue$-$>FirstPacketTime()$ \COMMENT{Save the timestamp of the first packet in the Queue, that is also the oldest}
\STATE $now \leftarrow$ read current time
\STATE $delta \leftarrow now - oldestInQueue$
\IF{$delta > IFQmaxDel$}
\STATE $IFQmaxDel \leftarrow delta$
\ENDIF
\end{algorithmic}
\end{algorithm}

\begin{algorithm}
\label{Pseudocode 3}
\caption{}
\begin{algorithmic}[1]
\STATE $windowSplit \leftarrow totalAwnd / activeFlows$
\FOR{\textbf{each} active flow \textit{i}}
%\IF{$limitFlow[i]$ is true}
\IF{$VoAPactive(i)$}
\STATE $awnd(i) \leftarrow (awnd(i) + windowSplit) / 2$
\ENDIF
\ENDFOR
\end{algorithmic}
\end{algorithm}

\begin{algorithm}
\label{Pseudocode 4}
\caption{}
\begin{algorithmic}[1]
\STATE $windowSplit \leftarrow totalAwnd / activeFlows$
\FOR{\textbf{each} active flow \textit{i}}
\IF{$VoAPactive(i)$}
\STATE $diff = windowSplit - cwnd(i)$
\IF{$diff < 0$}
\STATE $needMoreBW[i] \leftarrow true$
\STATE $flowsInNeed \leftarrow flowsInNeed + 1$
\STATE $awnd(i) \leftarrow (awnd(i) + windowSplit) / 2$
\ELSE
\STATE $diff = windowSplit - (cwin(i) + 10\%)$
\IF{$diff < 0$}
\STATE $awnd(i) \leftarrow (awnd(i) + windowSplit) / 2$
\ELSE
\STATE $BWLeftover \leftarrow BWLeftover + diff$
\STATE $awnd(i) = cwnd(i) + 10\%$
\ENDIF
\ENDIF
\ENDIF
\ENDFOR
\IF{$BWLeftover > 0$ and $flowsInNeed > 0$}
\STATE $split \leftarrow BWLeftover / flowsInNeed$
\FOR{\textbf{each} flow \textit{i}}
\IF{$needMoreBW[i]$}
\STATE $awnd(i) \leftarrow windowSplit + split$
\ENDIF
\ENDFOR
\ENDIF
\end{algorithmic}
\end{algorithm}

\section{Experimental Assessment}

%\subsection{Simulator and scenario}
In order to assess the goodness of our proposal we have chosen to run the simulations in a well known simulation environment: Network Simulator 2 (NS2). Our intention is to reproduce a realistic scenario, complex enough to simulate a real home environment.

\begin{figure}[h]
\centering
\includegraphics[scale=0.12]{scenario}
\caption{The considered scenario.}
\label{scenario}
\end{figure}

In the considered scenario (in Figure~\ref{scenario}) there are wireless devices connected to the AP (where VoAP is deployed), and wired nodes that represent remote resources in the cloud. All the wired connections have a 100~Mbps capacity, and the wireless channel is a IEEE~802.11g representing the bottleneck of the connection. The Wi-Fi AP is configured with a buffer size of 250 packets in order to be coherent with real implementations~\cite{Buffer1,Buffer2}.
The one way delay between the resources (servers) and clients is 40~ms and the flows we run in the scenario are those shown in the Table~\ref{table:nonlin}.

\begin{table}[ht]
\caption{Network flows} % title of Table
\centering % used for centering table
\begin{tabular}{c c c c c} % centered columns (4 columns)
\hline\hline %inserts double horizontal lines
Application & Protocol & From & To & Start/End (s)\\ [0.5ex] % inserts table
%heading
\hline % inserts single horizontal line
Download (FTP) & TCP & W(3) & node\_(3) & 100/250\\
Thin Client - S to C & UDP & W(1) & node\_(1) & 1/250\\
Thin Client - C to S & UDP & node\_(1) & W(1) & 1/250\\
Video chat S to C & UDP & W(2) & node\_(2) & 50/250\\
Video chat C to S & UDP & node\_(2) & W(2) & 50/250 \\ [1ex] % [1ex] adds vertical space
\hline %inserts single line
\end{tabular}
\label{table:nonlin} % is used to refer this table in the text
\end{table}

To increase the trustworthiness of our experimentation we employ real traffic traces that mimic the considered applications. For instance, the video chat is based on the traffic generated by a real webcam based video chat. The gaming UDP flow employed corresponds to a thin client game system, thus requiring high data rates for the video stream from the server to the client and a thin game action stream from the client to the server. To reproduce a realistic scenario, we have adopted the traces gathered in~\cite{Claypool2012}, which have been collected using the OnLive thin client game system with different categories of games~\cite{OnLive}.
A characteristic of thin client game systems is the ability to adapt the quality of the streamed video feed based on network conditions. Among those reported in~\cite{Claypool2012}, we chose to employ the traces corresponding to flows whose data rate is best suited to our wireless home network scenario.
Moreover, we consider two different game categories: first person shooter and strategic.

Among those analysed in~\cite{Claypool2012} we adopt the \emph{Unreal Tournament III} (UT) trace in its 10~Mbps limited downstream version and \emph{Grand Ages: Rome} (Rome) in all its variants. More 
detailed information about the game flows and their characteristic are provided in Table~\ref{table:games}.

\begin{table}[h]
\caption{Thin client games} % title of Table
\centering % used for centering table
\begin{tabular}{c c c c} % centered columns (4 columns)
\hline\hline %inserts double horizontal lines
Name & Packet Size & Interarrival & Restrictions \\ [0.5ex] % inserts table
%heading
\hline % inserts single horizontal line
UT & 947 B & 1.2 ms & 10 Mbps downstream limited links \\
Rome & 914 B & 1.6 ms & Unlimited \\ [1ex] % [1ex] adds vertical space
\hline %inserts single line
\end{tabular}
\label{table:games} % is used to refer this table in the text
\end{table}


\section{Results}
\label{Results}

We have discussed VoAP's desirable properties throughout Section~\ref{VoAP}. Some of these properties can actually be verified experimentally. To this end, in this section we assess through 
simulation \textbf{Properties 3, 4, 6, 7}.

\subsection{Demonstration of Property 3: Low Per-Packet Latency}
\label{Resultslatency}

One of the main purposes of VoAP is to reduce the negative effects of TCP over concurrent UDP-based real-time applications, which in our scenario translates to cloud based gaming session.
In particular we want to avoid the latency peaks caused by the TCP congestion control algorithm, as stated by \textbf{Property~3} discussed in Section~\ref{VoAP}.

Figure~\ref{onliveUT_Q_reno} shows the peaks caused by TCP New Reno with a highest peak amounting at 121~ms. With VoAP instead, the picture drastically changes and the outcome is shown 
in Figure~\ref{onliveUT_Q_voap}, with the highest peak reaching a 18~ms delay, showing an improvement of 85\%.


\subsection{Demonstration of Property 4: No Sacrifice of Throughput}
\label{Resultsthroughput}

%\begin{figure}[h]
%\centering
%\includegraphics[scale=0.32]{ifqdel_ut_reno}
%\caption{UT flow queue time using New Reno.}
%\label{onliveUT_Q_reno}
%\end{figure}

%\begin{figure}[h]
%\centering
%\includegraphics[scale=0.32]{bw_ut_reno}
%\caption{UT flow bandwidth using New Reno.}
%\label{onliveUT_BW_reno}
%\end{figure}

\begin{figure*}
\centering
\subfloat[Regular]{\includegraphics[scale=0.32]{ifqdel_ut_reno}\label{onliveUT_Q_reno}}\hfill
\subfloat[VoAP]{\includegraphics[scale=0.32]{ifqdel_ut_voap}\label{onliveUT_Q_voap}}
\caption{Bottleneck queuing delay evolution in the UT OnLive scenario.}
\label{ut_queue_time_comparison} %last one
\end{figure*}

%\begin{figure}[ht]
%\centering
%\includegraphics[scale=0.32]{ifqdel_ut_voap}
%\caption{UT flow queue time using VoAP.}
%\label{onliveUT_Q_voap}
%\end{figure}

%\begin{figure}[ht]
%\centering
%\includegraphics[scale=0.32]{bw_ut_voap}
%\caption{UT flow bandwidth using VoAP.}
%\label{onliveUT_BW_voap}
%\end{figure}

\begin{figure*}
\centering
\subfloat[Regular]{\includegraphics[scale=0.32]{bw_ut_reno}\label{onliveUT_BW_reno}}\hfill
\subfloat[VoAP]{\includegraphics[scale=0.32]{bw_ut_voap}\label{onliveUT_BW_voap}}
\caption{Bandwidth comparison at the in the UT OnLive scenario.}
\label{ut_bandwidth_comparison} %last one
\end{figure*}

The previous results would not be satisfactory if we have to sacrifice TCP in terms of throughput. We also want to allow the TCP flow to exploit the same bandwidth that it would have reached without the use of VoAP.

To this end, Figure \ref{onliveUT_BW_reno} shows the bandwidth trend of the TCP flow without enforcing VoAP. From the chart It can be seen how loss induces bandwidth fluctuations in syntony with 
the peaks in Figure~\ref{onliveUT_Q_reno}.
Using VoAP instead, the absence of latency peaks in Figure~\ref{onliveUT_Q_voap} is reflected by a more stable bandwidth without any loss incurred, as shown in Figure~\ref{onliveUT_BW_voap}.

The difference between the throughput in the two experiments is below the 1\%. We can state that the employment of VoAP does not harm the TCP flows, henceforth \textbf{Property~4} stated in 
Section~\ref{VoAP} is satisfied. This result is also confirmed when employing the Rome trace (Figures~\ref{rome_queue_time_comparison},~\ref{rome_bandwidth_comparison}). 

%\begin{figure}[h]
%\centering
%\includegraphics[scale=0.32]{ifqdel_rome_reno}
%\caption{Rome flow queue time using New Reno.}
%\label{onliveR_Q_reno}
%\end{figure}

%\begin{figure}
%\centering
%\includegraphics[scale=0.32]{bw_rome_reno}
%\caption{Rome flow bandwidth using New Reno.}
%\label{onliveR_BW_reno}
%\end{figure}

\begin{figure*}
\centering
\subfloat[Regular]{\includegraphics[scale=0.32]{ifqdel_rome_reno}\label{onliveR_Q_reno}}\hfill
\subfloat[VoAP]{\includegraphics[scale=0.32]{ifqdel_rome_voap}\label{onliveR_Q_voap}}
\caption{Bottleneck queuing delay evolution in the Rome OnLive scenario.}
\label{rome_queue_time_comparison} %last one
\end{figure*}

%\begin{figure}[t]
%\centering
%\includegraphics[scale=0.32]{ifqdel_rome_voap}
%\caption{Rome flow queue time using VoAP.}
%\label{onliveR_Q_voap}
%\end{figure}

%\begin{figure}[t]
%\centering
%\includegraphics[scale=0.32]{bw_rome_voap}
%\caption{Rome flow bandwidth using VoAP.}
%\label{onliveR_BW_voap}
%\end{figure}

\begin{figure*}
\centering
\subfloat[Regular]{\includegraphics[scale=0.32]{bw_rome_reno}\label{onliveR_BW_reno}}\hfill
\subfloat[VoAP]{\includegraphics[scale=0.32]{bw_rome_voap}\label{onliveR_BW_voap}}
\caption{Bandwidth comparison at the bottleneck in the Rome OnLive scenario.}
\label{rome_bandwidth_comparison} %last one
\end{figure*}

%\begin{figure}[t]
%\centering
%\includegraphics[scale=0.32]{cdf_ut}
%\caption{CDF of queuing delay in the UT trace scenario.}
%\label{onliveUT_CDF}
%\end{figure}

%\begin{figure}[t]
%\centering
%\includegraphics[scale=0.32]{cdf_rome}
%\caption{CDF of queuing delay in the Rome trace scenario.}
%\label{onliveRome_CDF}
%\end{figure}

\begin{figure*}
\centering
\subfloat[UT]{\includegraphics[scale=0.32]{cdf_ut}\label{onliveUT_CDF}}\hfill
\subfloat[Rome]{\includegraphics[scale=0.32]{cdf_rome}\label{onliveRome_CDF}}
\caption{Bottleneck queuing delay CDF.}
\label{cdf_configuration} %last one
\end{figure*}

Figure~\ref{cdf_configuration} shows a complementary view, reporting the cummulative distribution function (CDF) of the UT and Rome scenario, respectively. It is clear that VoAP outperforms 
the regular deployment in both scenarios, incurring less delays, reaching a near 100\% per-packet delay at around 20 ms.

Furthermore, we studied the average throughput achieved by the TCP flow in the scenario with a concurrent UT game flow and VoAP employing different values for $\alpha$ in the interval between
0 and 10 ms with a 1~ms step increment. The outcome is, as anticipated in Section IV, that almost any $\alpha$ value between 0 and $\beta$ does not significantly impact on the performance. Thereby 
it does not necessarily require an optimization study. For completeness we report the statistical significance of the data obtained from the ten runs having a mode of 5.37 Mbps, lower peak 
at 5.17~Mbps, higher peak at 5.38~Mbps and a standard deviation of 0.097.

Referring to \textbf{Property~4} discussed in Section~\ref{VoAP}, we also want to make sure that the slow start phase is not disabled by VoAP. To this end, Figure~\ref{onliveR_BW_voap} evidences that the initial growth of a TCP flow is exponential, ensuring that VoAP correctly enforces the property.

The trend of the charts shown until now regarding the TCP's throughput are shaped by the use of VoAP on the AP. When considering a traditional scenario, TCP's throughput follows the well 
known saw-tooth shaped fluctuations of the congestion window, which determines the actual sending window. Instead with VoAP, the sending window is shaped by the advertised window as the 
sending window is the minimum between the congestion window and the advertised window.

Therefore, to understand the rational behind the throughput and per-packet delay discussed in previous charts we compare the congestion window of regular TCP flows (Figure~\ref{cwnd_ut_reno} 
for UT and Figure~\ref{cwnd_rome_reno} for Rome) with the advertised window generated by VoAP (Figure~\ref{advwnd_ut_voap} for UT and Figure~\ref{advwnd_rome_voap} for Rome), which correspond 
to the factual sending windows in the two cases. As expected, with regular TCP and no VoAP enforced, we have a saw-tooth shaped fluctuation of the congestion window which generates queuing delays, 
congestion losses and throughput variations, whereas with VoAP we have a smoother progression of the advertised window which ensures a stable throughput and limits queuing delays.


%\begin{figure}[h]
%\centering
%\includegraphics[scale=0.32]{cwnd_ut_reno}
%\caption{Congestion window of the TCP flow (New Reno) with UT OnLive flow.}
%\label{cwnd_ut_reno}
%\end{figure}

%\begin{figure}[h]
%\centering
%\includegraphics[scale=0.32]{advwnd_ut_voap}
%\caption{Advertised window of the TCP flow (VoAP) with UT OnLive flow.}
%\label{advwnd_ut_voap}
%\end{figure}

\begin{figure*}
\centering
\subfloat[Regular]{\includegraphics[scale=0.32]{cwnd_ut_reno}\label{cwnd_ut_reno}}\hfill
\subfloat[VoAP]{\includegraphics[scale=0.32]{advwnd_ut_voap}\label{advwnd_ut_voap}}
\caption{Sending window comparison between regular and VoAP scenarios with the UT OnLive flow.}
\label{comparison_cwmd_advw_ut} %last one
\end{figure*}

%\begin{figure}
%\centering
%\includegraphics[scale=0.32]{cwnd_rome_reno}
%\caption{Congestion window of the TCP flow (New Reno) with Rome OnLive flow.}
%\label{cwnd_rome_reno}
%\end{figure}

%\begin{figure}[h]
%\centering
%\includegraphics[scale=0.32]{advwnd_rome_voap}
%\caption{Advertised window of the TCP flow (VoAP) with Rome OnLive flow.}
%\label{advwnd_rome_voap}
%\end{figure}

\begin{figure*}
\centering
\subfloat[Regular]{\includegraphics[scale=0.32]{cwnd_rome_reno}\label{cwnd_rome_reno}}\hfill
\subfloat[VoAP]{\includegraphics[scale=0.32]{advwnd_rome_voap}\label{advwnd_rome_voap}}
\caption{Sending window comparison between regular and VoAP scenarios with the Rome OnLive flow.}
\label{comparison_cwmd_advw_rome} %last one
\end{figure*}

\subsection{Demonstration of Property 6: Bandwidth Fair Share}
\label{Resultsfairness}

In a common wireless home scenario there is certainly more than one TCP flow at a time. With \textbf{Property~6} discussed in Section~\ref{VoAP} we state that every flow should be able to 
achieve a fair share of the available bandwidth. We modified the scenario by running a TCP flow from the start, and let two other flows enter the scenario after 70 s and 140 s respectively. 
The results are shown in Figure~\ref{diff_time}, where it is clear how the flows bandwidth is halved after the activation of the second flow, and is reduced to 1/3 of the original value when 
even the third flow is activated. The two charts corresponding to the other two flows show the same trend as they all fairly share the available bandwidth; we do not show them here to avoid 
redundancy and for lack of space.

\begin{figure}[h]
\centering
\includegraphics[scale=0.32]{diffTime}
\caption{Bandwidth of a TCP flow when other similar flows enter the channel.}
\label{diff_time}
\end{figure}

\subsection{Demonstration of Property 7: Redistribution of Unexploited Bandwidth}
\label{Resultsefficient}

As there might be some flows not fully exploiting their fair share of the available bandwidth, \textbf{Property 7} states that the possible leftover must be redistributed. To show that this 
property is fulfilled we modify the scenario, replacing the TCP flow with the configuration detailed in Table~\ref{table:multi}.

The char depicted in Figure~\ref{diff_flows} shows how the bandwidth exploited by the first flow is halved when the channel is shared with a second, unrestricted flow (starting at 40~s and 
ending at 80~s), and how the leftover is reallocated to the first flow when a second flow does not fully exploit its fair share of the bandwidth (starting at 120~s and ending at 160~s).

\begin{table}[ht]
\caption{Heterogeneous flows scenario} % title of Table
\centering % used for centering table
\begin{tabular}{c c c} % centered columns (4 columns)
\hline\hline %inserts double horizontal lines
Start & Stop & Limitation \\ [0.5ex] % inserts table
%heading
\hline % inserts single horizontal line
0 s & 200 s & Unlimited \\
40 s & 80 s & Unlimited \\
120 s & 160 s & 1 Mbps \\ [1ex] % [1ex] adds vertical space
\hline %inserts single line
\end{tabular}
\label{table:multi} % is used to refer this table in the text
\end{table}

\begin{figure}[h]
\centering
\includegraphics[scale=0.32]{diffFlow}
\caption{TCP bandwidth reallocation with heterogeneous flows entering and leaving the channel.}
\label{diff_flows}
\end{figure}

\section{Conclusion}
We considered a realistic scenario where in-home entertainment is delivered to wireless devices through a home gateway from cloud-based services. Our analysis focused on tackling the flow coexistence problem among concurrent transmissions of two kinds of different streams: them being TCP-based elastic (e.g., downloading) applications and the latter being UDP-based real-time (e.g., video streaming and online gaming) applications.

The contrasting \emph{modus operandi} of the above transport protocols is further exacerbated  by the downlink requirements posed by cloud based gaming whose flow if not properly accommodated could be impaired by persistent TCP-based flows.

To solve this problem, we proposed an algorithm (VoAP) consisting in an augmented AP. Our algorithm was inspired by TCP Vegas, whose factual deploy \emph{per
se} is not practical as its benefits are exploited when all TCP-based flows are of the same nature. Exhaustive experimental assessments employing real trace and synthetic flows show that the algorithm effectively
provides to both kinds of transmissions the possibility  to reach high throughput and low per-packet delay, significantly improving the network performance and session interactivity in a realistic wireless
home.

% if have a single appendix:
%\appendix[Proof of the Zonklar Equations]
% or
%\appendix  % for no appendix heading
% do not use \section anymore after \appendix, only \section*
% is possibly needed

% use appendices with more than one appendix
% then use \section to start each appendix
% you must declare a \section before using any
% \subsection or using \label (\appendices by itself
% starts a section numbered zero.)
%

% use section* for acknowledgement
%\section*{Acknowledgment}
%The authors would like to thank...


% Can use something like this to put references on a page
% by themselves when using endfloat and the captionsoff option.
\ifCLASSOPTIONcaptionsoff
  \newpage
\fi



% trigger a \newpage just before the given reference
% number - used to balance the columns on the last page
% adjust value as needed - may need to be readjusted if
% the document is modified later
%\IEEEtriggeratref{8}
% The "triggered" command can be changed if desired:
%\IEEEtriggercmd{\enlargethispage{-5in}}

% references section

% can use a bibliography generated by BibTeX as a .bbl file
% BibTeX documentation can be easily obtained at:
% http://www.ctan.org/tex-archive/biblio/bibtex/contrib/doc/
% The IEEEtran BibTeX style support page is at:
% http://www.michaelshell.org/tex/ieeetran/bibtex/
%\bibliographystyle{IEEEtran}
% argument is your BibTeX string definitions and bibliography database(s)
%\bibliography{IEEEabrv,../bib/paper}
%
% <OR> manually copy in the resultant .bbl file
% set second argument of \begin to the number of references
% (used to reserve space for the reference number labels box)
\begin{thebibliography}{1}

%\bibitem{IEEEhowto:kopka}
%H.~Kopka and P.~W. Daly, \emph{A Guide to \LaTeX}, 3rd~ed.\hskip 1em plus
%  0.5em minus 0.4em\relax Harlow, England: Addison-Wesley, 1999.

%\bibitem{IEEEhowto:kopka}
%H.~Kopka and P.~W. Daly, \emph{A Guide to \LaTeX}, 3rd~ed.\hskip 1em plus
%  0.5em minus 0.4em\relax Harlow, England: Addison-Wesley, 1999.

\bibitem{OnLive}
$www.onlive.com$ Accessed in 2014.

\bibitem{Claypool2012}
M. Claypool, D. Finkel, A. Grant, M. Solano, ``Thin to Win? Network Performance Analysis of the OnLive Thin Client Game System'', in Proc. of the ACM Annual Workshop on Network and Systems 
Support for Games (NetGames), Venice, Italy, 2012.

\bibitem{BoussettaMaggiorini}
A. Kaiser, D. Maggiorini, N. Achir, K.Boussetta, ``On the Objective Evaluation of Real-Time Networked Games,'' in Proc. of IEEE Global Telecommunications Conference (GLOBECOM), 
Honolulu, Hawaii, USA, 2009.

\bibitem{refPerPacketLatency} C. E. Palazzi, G. Pau, M. Roccetti, M. Gerla, ``In-Home Online Entertainment: Analyzing the Impact of the Wireless MAC-Transport Protocols Interference,'' in 
Proc. of the IEEE International Conference on Wireless Networks, Communications and Mobile Computing (WIRELESSCOM), Maui, HI, USA, 2005.

\bibitem{vegas1}
S. Low, L. Peterson, L. Wang, ``Understanding TCP Vegas: Theory and Practice'', Princeton University, Princeton, New Jersey, 2000.

\bibitem{KuroseRoss}
J. F. Kurose, K. W. Ross, \emph{Computer Networking: A Top-Down Approach Featuring the Internet}, Addison Wesley Longman, Boston, MA, USA, 2001.

\bibitem{OC48}
H. Jiang, C. Dovrolis, ``Why Is the Internet Traffic Bursty in Short (sub-RTT) Time Scales?'', in Proc. of the ACM SIGMETRICS 2005, Banff, AL, Canada, 2005.

\bibitem{Maggiorini2004}
A. Balk, M. Gerla, M. Sanadidi, D. Maggiorini, ``Adaptive Video Streaming: Pre-encoded MPEG-4 with Bandwidth Scaling'', Elsevier Computer Networks 44(4), 2004.

\bibitem{dash}
I. Sodagar, ``The MPEG-DASH Standard for Multimedia Streaming over the Internet''. IEEE MultiMedia 18(4), 2011.


\bibitem{WCMC2013}
M. Gerla, D. Maggiorini, C. E. Palazzi, A. Bujari, ``A Survey on Interactive Games over Mobile Networks'', Wiley Wireless Communications and Mobile Computing 13(3), 2013.

\bibitem{80211}
IEEE, ``Standard for Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications'', Specifications, ISO/IEC 8802-11:1999(E), 1999.

\bibitem{PantelWolf2002}
L. Pantel, L. C. Wolf, ``On the Impact of Delay on Real-Time Multiplayer Games'', in Proc. of the ACM International Workshop on Network and Operating Systems Support for Digital Audio 
and Video (NOSSDAC), Miami, FL, USA, 2002.

\bibitem{80211e}
IEEE Standard for Information Technology, ``Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks - Specific Requirements Part 11: 
Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Amendment: Medium Access Control (MAC) Quality of Service Enhancements'', P802.11e/D13.0, 2005.

\bibitem{vegas2}
L. S. Brakmo, L. L. Peterson, ``TCP Vegas: End to End Congestion Avoidance on a Global Internet'', IEEE Journal on Selected Areas in Communications 13(8), 2002.

\bibitem{sap1}
C. E. Palazzi, S. Ferretti, M. Roccetti, G. Pau, M. Gerla, ``What's in That Magic Box? The Home Entertainment Center's Special Protocol Potion, Revealed'', IEEE Transactions on Consumer 
Electronics 52(4), 2006.

\bibitem{sap2}
C. E. Palazzi, N. Stievano, M. Roccetti, ``A Smart Access Point Solution for Heterogeneous Flows'', in Proc. of the International Conference on Ultra Modern Telecommunications and 
Workshops (ICUMT), St. Petersburg, Russia, 2009.

\bibitem{gap1}
S. M. El Rakabawy, A. Klemm, C. Lindemann, ``Gateway Adaptive Pacing for TCP Across Multihop Wireless Networks and the Internet'', in Proc. of the ACM International Symposium on Modeling 
Analysis and Simulation of Wireless and Mobile Systems (MSWiM), Torremolinos, Spain, 2006.

\bibitem{mhop-not-gap}
K. Kim, D. S. Niculescu, S. Hong, ``Coexistence of VoIP and TCP in Wireless Multihop Networks'', IEEE Communications Magazine 47(6), 2009.

\bibitem{Buffer1}
T. Li, D. Leith, D. Malone, ``Buffer Sizing for 802.11 Based Networks'', IEEE/ACM Transactions on Networking 19(1), 2011.

\bibitem{Buffer2}
$www.bufferbloat.net/projects/bloat/wiki/Linux_Tips$ Accessed in 2014.

\bibitem{performanceThin}
Y.-C. Chang, P.-H. Tseng, K.-T. Chen, and C.-L. Lei, ``Understanding the Performance of Thin-Client Gaming,'' in Proc. of IEEE Communications Quality and Reliability (CQR), Naples, FL, USA, 2011.

\end{thebibliography}

\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{bujari_pic}}]{Armir Bujari}
received his Ph.D. degree in Computer Science at the University of Padua, Italy, under the supervision of Professor Claudio E.
Palazzi. He previously completed his M.S in Computer Science, Summa Cum Laude, at the same university. His research interests include protocol 
design and analysis for wireless networks and delay-tolerant communication in mobile networks. On these topics, he is active in several technical 
program committees in international conferences and is co-author of more than 15 papers, published in international conference proceedings, 
books, and journals.
\end{IEEEbiography}%
\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{michele_pic}}]{Michele Massaro}
is a M.S student in Computer Science and is currently completing his thesis in the MobileLab laboratory, Padua, under the supervision of Prof. 
Claudio Enrico Palazzi. His research interests include protocol design and analysis for wireless networks and cloud computing.
\end{IEEEbiography}%
\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{palazzi_pic}}]{Claudio Enrico Palazzi}
is Associate Professor with the Department of Mathematics, University of Padua, Italy. He was the first student
enrolled in the joint Ph.D. program in Computer Science organized by University of Bologna (UniBO) and University of California, Los Angeles
(UCLA). Through this program, he received his M.S. degree in Computer Science from UCLA in 2005, his Ph.D. degree in Computer Science from UniBO in 2006,
and his Ph.D. degree in Computer Science from UCLA in 2007. From 2007 to 2010 he was Assistant Professor at the
Department of Mathematics of the University of Padua. His research is primarily focused on protocol design and
analysis for wired/wireless networks, with emphasis on network-centric multimedia entertainment and vehicular
networks. On these topics, he is active in various technical program committees in prominent international conferences
and is co-author of more than 100 papers, published in international conference proceedings, books, and journals.
\end{IEEEbiography}

\vfill

% Can be used to pull up biographies so that the bottom of the last one
% is flush with the other column.
%\enlargethispage{-5in}



% that's all folks
\end{document}


